Various organizations make use of enterprise resource planning (ERP) software architectures to provide an integrated, computer-based system for management of internal and external resources, such as for example tangible assets, financial resources, materials, customer relationships, and human resources. An ERP software architecture is an example of a service oriented business framework that can, in some examples, be designed to facilitate the flow of information between business functions inside the boundaries of the organization and to manage connections to outside service providers, stakeholders, and the like. Such architectures often include one or more centralized databases accessible by a core software platform that consolidates business operations, including but not limited to those provided by the core software platform and one or more third party vendors, into a uniform and organization-wide system environment. The core software platform can reside on a centralized server or alternatively be distributed across modular hardware and software units that provide “services” and communicate via one or more direct or networked connections, for example over a network such as the Internet, a wide area network, a local area network, or the like.
As part of the installation process of the core software platform on computing hardware owned or operated by the organization, one or more customized features, configurations, business processes, or the like may be added to the default, preprogrammed features such that the core software platform is configured for maximum compatibility with the organization's business processes, data, and the like.
Business objects or other data objects in an object-oriented computer program, such as for example an ERP, can represent the entities in a business domain that the object-oriented computer program is designed to support. A business object can encapsulate all or at least some of the data and business behavior associated with the entity that it represents. In some applications, a business object can be modeled and implemented in a normalized manner to optimize service provisioning. Joined data of other business objects for use in a user interface, a form, an agent, a data analytic routine or module, or the like may be more efficiently accessed using one or more denormalized views. A service adaptation can provide a mapping facility to fill the gap between a provider layer, for example one or more repositories storing data and data objects, and a consumer layer that accesses the data and data objects.
Service adaptations can include frontend service adaptations that allow for the combination of fields from different business object nodes so that a resulting adapted business object node can be used for displaying required business data in a user interface. With frontend service adaptation, an adapted business object node can be configured to contain fields from different business object nodes along an association path. Such an arrangement can result in a large amount of metadata residing and being processed by a frontend server. In addition, during runtime, all data on an associated path is transferred to the frontend server. Moreover, many association paths may need to be evaluated on the frontend in order to access required business object fields. All of such requirements relating to frontend service adaptation can negatively affect performance, network data volume, memory consumption, and response time for the corresponding user interfaces. Alternative approaches, described in co-pending and co-owned U.S. patent application Ser. Nos. 12/246,247, 12/648,206, and 12/648,216, the disclosures of each of which are incorporated herein by reference in their entireties, can include shifting service adaptation to the backend to improve performance, network data volume, memory consumption, response times, and the like.